A “model” generally describes one or more complex application artifacts (e.g., business processes, data structures, structure and behavior of software systems or other technical and/or business components, etc.) in a formalized fashion. A model can use modeling primitives and/or conventions of a well-defined “abstract language,” which oftentimes is referred to as a metamodel. Some common metamodels are the UML family of modeling languages (e.g., UML class diagrams, UML collaboration diagrams, etc.), the BPMN metamodel, the ARIS family of modeling languages (EPC, VAC, FAD, etc.), the entity-relationship (meta)model (ERM), the relational (meta)model, etc. A metamodel, being an abstract language, may be thought of as a collection of modeling elements that can be used or “instantiated” to describe the actual models. For instance, in a UML class diagram, modeling elements include classes, associations, properties, etc., whereas the model elements in the relational model include relations and their attributes. These modeling elements can be arranged in a variety of well-defined ways to build formal models representing potentially complex business and/or technical processing or other flows.
A metamodel is in principle independent of a concrete notation and therefore may be thought of as an “abstract language,” as indicated above. For instance, a metamodel may define only the language concepts and the rules for their use to form a valid model for the metamodel itself. To do actual modeling with a metamodel, however, a concrete notation is required. Notations of metamodel elements include, for example, boxes with three “compartments” that represent UML classes, labeled rectangles and diamonds used to represent entities and relationships in the ERM, etc.
A common trait of many metamodels is that corresponding models can be represented as a graph including nodes and edges, which collectively can be referred to as the graph's “elements.” Computer systems handling different “kinds” of models (e.g., so-called model management systems) often use some kind of graph model as internal representation for all kinds of models.
There are many circumstances in which it would be desirable to compare two or more different models with one another. For instance, it might be desirable to compare two or more different models with one another during model merging, for version control purposes, when model development is performed by multiple users, etc. It is possible to use certain existing tools for model comparison purposes.
Unfortunately, however, it oftentimes is difficult to compare multiple different arbitrary models. In other words, while it is relatively straightforward to compare identical elements in different models where there is only one element with a given comparison-identifier (e.g., an element name) in each model, it is considerably more difficult to identify corresponding elements when there is more than just one object with the same name in the different models.
The assignee of the instant invention has implemented a model comparison tool within its ARIS Business Architect system. However, this comparison tool was implemented with a view towards comparing model-versions as opposed to comparing arbitrary models. As a result, it simply compared the unique ARIS-Object-ID (OID) of the different elements. This comparison is always unique, even if there are many elements with the same comparison-identifier. The problems associated with comparing arbitrary models therefore were not completely solved. In this regard, in the existing solution, for identifying corresponding elements, a user could only identify elements if all of their neighbors were unique from the beginning, or if the non-unique elements had the same size and top/left position. These conditions are very rarely fulfilled because of the nature of the modeling process.
Thus, it will be appreciated that there is a need in the art for an improved model-comparison tool that has a better identification algorithm. For instance, it will be appreciated that there is a need in the art for an improved model-comparison tool that handle comparisons between multiple arbitrary models, e.g., where multiple non-unique elements are connected with one another.
One aspect of certain example embodiments relates to a model comparison tool that works even when an occurrence-definition concept is applied and/or the ability to place multiple elements of same type and with same name in a model is enabled.
Another aspect of certain example embodiments relates to techniques for allowing a user to meaningfully compare models in cases where not all neighbors of a non-unique element are unique from the beginning.
Another aspect of certain example embodiments relates to a more deterministic approach to considering two or more different models, with those models potentially including multiple non-unique elements that are connected with one another.
In certain example embodiments, a computer-implemented method for comparing first and second computer-represented models is provided. Each said model has a plurality of elements and each said element has a (comparison)-identifier (e.g., the name-attribute or the GUID of the object definition in ARIS models). Sets of elements are built from the first and second models such that all elements in a given set have identical (comparison)-identifiers. For each set of elements: when the set includes exactly one element from each of the first and second models, these elements are marked as corresponding with one another; when the set includes at least one entry for the first model and no entries for the second model, the at least one entry for the first model is/are marked as having been deleted; and when the set includes at least one entry for the second model and no entries for the first model, the at least one entry for the second model is/are marked as having been added. However, when the set includes more than one element for either or both of the first and second models, for each element in the set from the first model an additional (e.g., unique) identifier (e.g., the OID, at least in the ARIS environment) of the element in the set from the first model is compared to all additional (unique) identifiers of the elements in the set from the second model. Then, when there is exactly one element from the second model that has the same additional (unique) identifier as the identifier of the element from the first model, the first and second elements are marked as corresponding with one another and the method proceeds to the next element in the set from the first model, if any. However, in situations where (i) there are no elements from the second model set that have the same additional (unique) identifier as the identifier of the element from the first model, and in situations where (ii) there are multiple elements from the second model that have the same additional identifier as the identifier of the element from the first model, a sub-process is performed, with the sub-process including: comparing a position of the element from the first model when positions of the elements from the second model, if any; when there is exactly one element from the second model that has the same position as the element from the first model, marking the first and second elements as corresponding with one another and proceeding to the next element in the set from the first model, if any; comparing neighbors of the element from the first model (if any) with neighbors of each elements from the second model (if any); determining whether (a1) exactly one element from the second model has more identified neighbors than other elements from the second model and these neighbors correspond to neighbors of the element from the first model; and determining, when part (a1) is not fulfilled, whether (b1) exactly one element of the second model has neighbors that are all identified and the first element also has these neighbors identified as corresponding neighbors. Then, in situations where neither (a1) nor (b1) apply, the process proceeds to the next element in the set from the first model, if any. In situations where (a1) or (b1) applies, a reverse or “vice versa” portion of the sub-process is performed so as to include: determining whether (a2) exactly one element from the first model has more identified neighbors than other elements from the first model and these neighbors correspond to neighbors of the element from the second model; determining, when part (a2) is not fulfilled, whether (b2) exactly one element of the first model has neighbors that are all identified and the second element also has these neighbors identified as corresponding neighbors; in situations where neither (a2) nor (b2) apply, proceeding to the next element in the set from the first model, if any; and in situations where (a2) or (b2) applies, comparing this element from the first model with the actual element from the first model being tested in this iteration and, when they are the same element, marking the element from the first and second models as corresponding to one another, but when this is not the case, proceeding to the next element in the set from the first model, if any. When all sets have been examined, it is determined whether any element could not be identified as corresponding during the last iteration. When at least one correspondence was identified, the iterations are repeated over all sets.
In certain example embodiments, there is provided a non-transitory computer-readable storage medium tangibly storing instructions that, when executed by at least one processor of a modeling system, perform the above-described and/or similar methods.
In certain example embodiments, a modeling system is provided. Processing resources include a processor and a memory. A model repository stores a plurality of computer-based models, with each said model including a plurality of model elements. A user interface is configured to receive user input. The processor is configured to receive user input from the user interface. When the user input indicates that the processing resources are to retrieve first and second models from the model repository and compare the two, the comparison is performed by executing instructions corresponding to the above-described and/or similar methods.
According to certain example embodiments, at least some of the identifiers are non-unique within a given model.
According to certain example embodiments, the positions that are compared are center positions of the elements.
According to certain example embodiments, a layout or design template is applied to the first and/or second models to provide a consistent orientation as between the models.
According to certain example embodiments, the second model is a different version of the first model, created from a merge operation performed on the first model, or a copy and subsequent alteration of the first model.
According to certain example embodiments, a display is configured to display one or more models in the model repository when the user input receives user input requesting a corresponding display, and is further configured to display results of the comparisons.
According to certain example embodiments, the techniques described above may be extended to accommodate comparisons between more than two models.
These features, aspects, advantages, and example embodiments may be used separately and/or applied in various combinations to achieve yet further embodiments of this invention.